What is the justification behind choosing FileHandle and not a file path or an fd? Is it because most of userland code uses FileHandles nowadays?

Using FileHandle is more or less the only reliable way of checking if a file exists to then proceed to read it in an async context, for this reason I think we should simplify its use when we can. fd are just numbers, I think it could be dangerous to add support for those, file paths are just strings. We could consider URL objects, but I'm not convinced that would make a very interesting API.

to read it in an async context

Hmm, would be nice to have a test case that tries to read lines from the file after a part of the stream has already been consumed if that's what you mean by the async context here.

By async context, I mean that you at some point need to know that the file exists, then at another point you need to read it and/or write to it. e.g.

async function* getLinesOrCreateFile(path) {
  let fh
  try {
    fh = await open(path, 'r');
  } catch (err) {
    if (err?.code === 'ENOENT') {
      await writeFile(path, getDefaultData());
      yield* getDefaultData();
      return;
    }
    throw err;
  }
  try {
    yield* readLines(fh);
  } finally {
    await fh.close();
  }
}

Ah, so something like a cache. This could still be done by accepting string filepaths, fds and url objects with some modifications like opening the file later on in the last try block and turning the open() call into access().

fd are just numbers, I think it could be dangerous to add support for those, file paths are just strings. We could consider URL objects, but I'm not convinced that would make a very interesting API.

I'm not sure how using these are dangerous though. Fd based APIs are not marked as deprecated or legacy and there is no mention of any sort of danger in the fs docs.

I didn't understand what's wrong with file paths being "just strings".

It seems that there are multiple ways in which users could prefer to use this functionality. I feel that adding support for anything other than just readable streams would serve as an impetus for PRs adding support for other things like fds, string paths and even url objects (you might not find the api interesting but someone else might :P). This would unnecessarily expand the API surface.

This could still be done by accepting string filepaths, fds and url objects with some modifications like opening the file later on in the last try block and turning the open() call into access().

Well no, the access call to a path could report there's a file that exists, then another program could delete it, which would create an error later when trying to read the file. See discussion in #39960 for more context.

I'm not sure how using these are dangerous though. Fd based APIs are not marked as deprecated or legacy and there is no mention of any sort of danger in the fs docs.

#37874 (comment)

I didn't understand what's wrong with file paths being "just strings".

What I mean is readLines('this is a line\nthis is another line') could be something that someone tries, I think it's more useful if it throws a useful error. Anyway, no strong feeling on my side for this, it's not what I'm looking for anyway.

It seems that there are multiple ways in which users could prefer to use this functionality. I feel that adding support for anything other than just readable streams would serve as an impetus for PRs adding support for other things like fds, string paths and even url objects (you might not find the api interesting but someone else might :P). This would unnecessarily expand the API surface.

That's a great point, that's why I suggest instead we make it a method of the FileHandle class.

Are we sure that this is the only option that needs to be set with a value different from the default while reading lines from a file?
Also, why isn't Infinity the default value of crlfDelay in all cases?

Are we sure that this is the only option that needs to be set with a value different from the default while reading lines from a file?

That's the documented one, we can always update it later if we find out some are missing.

Also, why isn't Infinity the default value of crlfDelay in all cases?

I don't have the answer to that question, I don't think adding an unnecessary breaking change is worth it.

I don't think adding an unnecessary breaking change is worth it

I thought doing that would fix the weird problems you were mentioning in #42590 (comment) instead of introducing unnecessary breakage. (would be interesting to know what the weird problem is though)

The unnecessary breakage is to change the default. See the docs for more context:

Is \r\n supposed to be considered as a single line even on posix? I thought line endings were \r on posix and \r\n on windows.

\r and \n are two different characters, \n is the one that marks the end of the line on non-Windows systems. readline will treat both as a line separator, unless there are next to one another.

lint fix